home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Apr 90 / MacApp.Tech$ 4⁄20⁄90 / 1148-More on external cod-Apr90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.7 KB  |  89 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item forwarded  by  LOOMIS       to GUITTET1
  4.  
  5. Item forwarded  by  LOOMIS       to COWSAR1      PLUMMER1     REKIETA1
  6.  
  7. Item    4067071                         19-April-90        10:19PDT
  8.  
  9. From:   KEMINK1                         Kemink, Joost
  10.  
  11. To:     MACAPP.TECH$                    MacApp Technical
  12.  
  13. Sub:    More on external code
  14.  
  15. MacAppers,
  16.  
  17. Since my car broke down this morning and thus forced me (sort of) to work at my
  18. home office (which is just a Mac on a table), I thought I might as well add
  19. some thoughts to the external code discussion.
  20.  
  21. In Xenon (discrete time finite duration signal processing), CUST resources are
  22. used to implement the signal processing functions. Without any CUST resources,
  23. the application "works" but has no functionality.
  24.  
  25. The user builds signal chains by dragging "Elements" into a view and connecting
  26. these Elements together by "Connections". Each Element represents some signal
  27. processing functionality such as a generator (an Element that creates data) or
  28. an operator (an Element that transforms data). Elements can have zero or more
  29. inputs and/or zero or more outputs. Elements may have parameters as well.
  30.  
  31. Due to the limited nature of the CUST resources in Xenon, each CUST resource
  32. only has a few subroutines (the appropriate one is identified by a routine
  33. selector, much like it is done in HyperCard). These routines are (roughly):
  34. Initialize, Free, Calculate and ModifyParameters. Initialize and Free allocate
  35. and release data needed by the CUST respectively. Calculate is the routine
  36. where the signal processing takes place, given any input data and parameters.
  37. ModifyParameters gets called when the user double-clicks on an Element. If, for
  38. example, the user double-clicks on a delay Element, a dialog box shows up that
  39. allows the user the adjust the delay.
  40.  
  41. Since these dialogs generally involve the user to type in some value, or maybe
  42. even adjust a slider control or something like that, it would require a lot of
  43. code to implement all these common things in every separate CUST resource. At
  44. this point, callbacks become useful.
  45. In some tests I did, the CUST resource is stored in a separate file together
  46. with a VIEW resource, and some other resources like PICT's and ICON's. When the
  47. CUST's ModifyParameters routine is being called, the CUST calls back a MacApp
  48. internal routine which creates a window with NewTemplateWindow, using the VIEW
  49. resource in the external code. The window is not yet displayed, since the
  50. values for various NumberText items may need to be adjusted to reflect the
  51. current parameter values. Once the MacApp internal routine returns,
  52. ModifyParameters adjusts the required NumberTexts by calling another MacApp
  53. internal which in turn calls the appropriate MacApp TNumberText method. Finally
  54. when all the values are set up correctly, ModifyParameters calls yet another
  55. MacApp internal which in turn calls PoseModally. Depending on the result of
  56. PoseModally, the external code either accepts the parameter changes or rejects
  57. them, and finally closes the window (yes, again by calling a MacApp internal).
  58.  
  59. From the scenario above, it follows that the mechanism needs quite a number of
  60. callbacks to the host application. As Keith mentioned, the set of callbacks may
  61. vary from application to application. Therefore I like his proposal of
  62. designing things according to function.
  63.  
  64. With respect to resource ID's, with Xenon I very quickly ran into problems with
  65. duplicate resource ID's when several people who wrote CUST resources
  66. independently wanted to add them to the host. In recent tests, I switched from
  67. resource ID's to resource names as the mechanism to select CUST's. Of course,
  68. name conflicts may arise as well, but they are less likely than ID conflicts.
  69. To reduce possible conflicts even further, I think that every 'package' should
  70. be contained in its own file. ('Package' being CUST resource plus possible
  71. other resources needed by it).
  72.  
  73. CUST's in Xenon are encapsulated in an object, the CUST's routines are called
  74. by corresponding methods in the object. In later tests, where the application
  75. continuously looks for external code in files, a "manager" takes care of
  76. searching one or more folders. A practical problem that arises here is the
  77. possibility that users can put external code files in folders and remove them
  78. later, this could very easily confuse the host application. Also, you have to
  79. very closely keep track of the resource chain, since you would like the host
  80. application to have access to its STR# resources to display an error message
  81. when the user enters an out-of-bounds value in the VIEW provided by the
  82. external code.
  83.  
  84. Hoping this adds to the interesting external code discussion, I remain without
  85. a car,
  86.  
  87. Joost Kemink
  88.  
  89.